As illustrated in FIG. 1A, link aggregation is a network configuration and process used to aggregate multiple links between a pair of nodes 120, 122 in the network to enable transmission of user data on each of the links participating in a Link Aggregation Group (LAG) 101 (see, e.g., Institute of Electrical and Electronics Engineers (IEEE) standard 802.1AX). Aggregating multiple network connections in this fashion can increase throughput beyond what a single connection can sustain, and/or can be used to provide resiliency in case of a failure of one of the links The “Distributed Resilient Network Interconnect” (DRNI) 102 (see Clause 8 of IEEE 802.1AX-REV/D1.0) specifies extensions to link aggregation in order to be able to use link aggregation on a network interface even between more than two nodes, for example between four nodes K, L, M and O as illustrated in FIG. 1B.
As shown in FIG. 1B, a LAG is formed between Network 150 and Network 152. More specifically, a LAG is formed between LAG virtual nodes or ‘portals’ 112, 114. The first LAG virtual node or portal 112 includes a first node (K) and a second node (L). The second LAG virtual node or portal 114 includes a third node (M) and a fourth node (O). These nodes can also be referred to as “Portal Systems”. Note that both the first and second LAG virtual nodes or portals 112, 114 may include a single or more than two nodes in a portal. LAG Nodes K and M are connected as peer nodes, and LAG Nodes L and O are also connected as peer nodes. As used in this application, a “LAG virtual node” refers to a DRNI portal in the IEEE documentation discussed above (i.e., two or more nodes that appear as a single node to their respective peers). Additionally, the statement that virtual node or portal 112 “includes” two nodes K, L means that the virtual node or portal 112 is emulated by the nodes K, L, this can be referred to as an “emulated system.” Similarly, the statement that virtual node or portal 114 “includes” two nodes M, O means that the virtual node or portal 114 is emulated by the nodes M, O. Note that link aggregation group 161 is also formed between K-M and L-O links.
Multiple nodes participating in the LAG appear to be the same virtual node or portal with a single System ID to their peering partner in the LAG. The System ID is used to identify each node (e.g., node K, node L, node M, and node O). The System ID is included in Link Aggregation Control Protocol Data Units (LACPDUs) sent between the individual partner nodes of the LAG (e.g., between K and M or between L and O). The System ID can be generated based on identifiers of the constituent nodes of a portal using any individual identifier or any combination thereof. A common and unique System ID for the corresponding LAG virtual node or portal can be consistently generated. Thus, as shown in FIG. 1B, node K and node L belong to the same Network 150 and they are part of the same DRNI Portal 112 (i.e., the same LAG virtual node), and use a common System ID of “K” for the emulated LAG virtual node 112. Similarly, Nodes M and O of Network 152 are seen as a single LAG virtual node or portal 114 with a System ID “M” by Nodes K and L.
FIG. 1B also shows the DRNI link allocation of a particular service (see bold link between K and M in FIG. 1B). The service allocation of an interface may involve a Virtual Local Area Network (VLAN), and an identifier for the service may be a VLAN Identifier (VID), such as a Service VID (i.e., “S-VID”) (typically identifying services on Network to Network Interfaces (NNIs)) or a Customer VID (i.e. “C-VID”) (typically identifying services on User to Network Interfaces (UNIs)). (Note that B-VIDs are indistinguishable from S-VIDs as they have the same Ethertype.) In the example of FIG. 1B, the service is allocated to the upper link (between upper nodes K, M). The upper link is thus chosen as the “working” link and the lower link (between nodes L, O) is the “standby” link or “protection” link. Service link allocation, i.e. using the same physical link for frame transmission both in the forward and in the backward directions is highly desirable.
Transmitted frames may be dynamically redistributed, and such redistribution may result from a removed or added link or a change in a load-balancing scheme. Traffic redistribution occurring in the middle of a traffic flow may cause disordered frames. In order to ensure that frames are not duplicated or reordered due to this redistribution, the Link Aggregation uses a Marker Protocol. The aim of using the Marker Protocol is to detect when all the frames of a given traffic flow are successfully received at a remote peer node. In order to accomplish this, LACP transmits Marker Protocol Data Units, PDUs, on each of the port channel links. The partner system responds to a received Marker PDU once it has received all the frames transmitted on this link prior to the Marker PDU. The partner system then sends a Marker response PDU for each received Marker PDU. Once the Marker response PDUs are received by the local system on all member links of the portal, the local system can redistribute the frames in the traffic flow thereby avoiding any risk of frame disordering. However, it can be problematic to ensure that a Marker response PDU works properly in a DRNI where either or both peer nodes of the LAG can comprise multiple systems. Measures must therefore be taken in order to ensure that frame ordering is maintained for certain sequences of frame exchanges—known as conversations—between ports in such LAGs.